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REMARKS 

Status 

This Amendment is submitted in response to the final Office Action of June 8, 2005 
(hereinafter "the Office Action"). Upon entry of this Amendment, claims 1, 27, 31, and 35 
are amended. Claims 1-6 and 27-38 are pending. All pending claims stand rejected under 35 
U.S.C. § 102(e) 

All references to the claims, except as noted, will be made with reference to the claim 
list above beginning on page 2. All references to "the Office Action," except as noted, will be 
referencing the most recent Office Action dated June 8, 2005. Except as noted or where the 
referenced document contains line numberings (e.g., a U.S. Patent), any line numbers 
referenced herein will count every printed line, except the page header, but including section 
headings. If there is any confusion or questions regarding any aspect of this Amendment, the 
Examiner is invited to contact the undersigned. 

Amendment 

Claim 1 is amended to address indefiniteness pointed out in the Office Action (page 2, 
lines 9-16). Independent claims 27, 31, and 35 are amended to address the Examiner's 
concern with regard to the phrase, "iteration splitting" mentioned with respect to claim 1 . 
Since the amendments merely address indefiniteness issues raised in the Office Action, no 
new matter has been introduced. Furthermore, the amendments do not raise any new issues 
requiring further consideration or search. Applicants therefore respectfully request entry of 
these amendments. 

Claim Rejections under 35 U.S.C. § 112, second paragraph 

Claim 1 stands rejected under 35 U.S.C. § 112, second paragraph. Specifically, the 
Office Action states that the phrase, "the discovering" in line 3 of claim 1 is vague and 
indefinite. The Office Action states that "Applicant's previous limitation 'discovering index 
expression...' has already been referenced to in the preceding claim limitation where 
Applicant states, '...index expressions discovered...'" (Office Action page 2, lines 9-10). 
Applicants respectfully disagree that the phrase is indefinite. However, for the purpose of 
furthering prosecution, Applicants have removed the phrase, "discovered by the discovering." 
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The Office Action also cites the limitation "trip counter and offset" in line 7 of claim 1 
as being indefinite for lacking sufficient antecedent basis. Applicants have removed "the", 
which precedes "trip counter and offset" and further identify "trip counter and offset" as being 
"portions of the index expressions." 

Finally, the Office states that the phrase "iteration splitting" set forth in line 8 of claim 
1 lacks sufficient antecedent basis (Office Action, page 2, lines 15-16). This is the first 
instance of that phrase in the claim and the phrase does not have a "the" or "said" in front of 
it. Thus, while there is no antecedent basis in the claim for "iteration splitting," none is 
needed. Applicants have endeavored to amend claim 1 by further defining iteration splitting 
to include generating a plurality of loops, each loop being based on an original loop structure 
of the loop portion. Again, since the term, "iteration splitting" is defined in the specification 
(page 17, lines 5-7), Applicants respectfully submit that no new issues are presented herein 
that would require further consideration and/or search. 



Claim Rejections under 35 U.S.C. § 102(e) 

Claims 1-38 stand rejected under 35 U.S.C. § 102(e) as being anticipated by U.S. 
Patent 6,519,765 to Kawahito et al. (Kawahito) (Office Action, page 3, lines 14-15). 
Applicants respectfully traverse because either the claim was previously canceled, or because 
the prior art fails to show each and every limitation set forth in the claims. 

With regard to claims 7-26, these claims were canceled in Applicants' previous 
Amendment. Since these claims have been canceled, they are not pending before the Office 
and therefore should not be rejected. Applicants respectfully request withdrawal of the 
rejection as it pertains to claims 7-26. 

Claims 1-6 and 27-38 set forth subject matter that is not present in the asserted prior 
art. For example, each of the independent claims 1, 27, 31, and 35 set forth, inter alia, 
"sorting the index expressions by trip counter and offset" (claim 1, lines 6-7; claim 27, lines 
6-7; claim 31, lines 10-11; and claim 35, lines 6-7). The Office Action states that Kawahito 
teaches, "for each of the arrays accessed using the index expressions, sorting the index 
expressions by the trip counter and offset and (3:35 - 60, for sorting see execution order, also 
see 7:10 - 20, for index expressions and offset)" (Office Action, page 3, lines 21-23). 
Applicant respectfully disagrees. 
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Kawahito teaches a method for reducing redundant array range checks in a compiler 
using three different methods: (A) loop versioning; (B) reverse data-flow analysis, and (C) 
forward data-flow analysis (column 3, lines 50-61). None of the methods disclosed by 
Kawahito anticipate the limitation mentioned above. 

Loop versioning generates multiple versions of a loop, wherein only one is executed 
depending upon the program state (column 10 lines 45 to 60). In the example given by 
Kawahito, a program loop shown in Table 6 generates two equivalent loops shown in Table 7, 
wherein one loop contains array range checks and the other does not. Only one loop is 
executed. The loop to be executed depends on the conditions at the start of the loop. This is 
different from the present invention wherein iteration splitting used. As defined in the present 
specification, iteration splitting distributes iterations of a single input loop into multiple 
output loops. See, e.g., page 17, lines 7-11, and Figure 10 and associated text. 

Much of Kawahito 's disclosure revolves around data-flow analysis. For background 
information on data-flow analysis, see, for example, the attached paper, "Data Flow Analysis" 
by Mathew Dwyer ("Dwyer"). This paper is being provided for definitions and background 
information on data-flow analysis described by Kawahito. Since the present invention does 
not relate to dataflow analysis, Dwyer is not being presented as prior art under 37 C.F.R. § 
1.56. Essentially, data-flow analysis involves generating a flow graph from the text of a 
computer program (either, source, object, or executable). See, e.g., Figure 1 on page 6 of 
Dwyer. The flow graph can be generated in forward program order, reverse program order, or 
a combination of forward and reverse. The flow graph generally comprises basic blocks 
connected by edges. Each edge represents a jump in program execution from one location to 
another in the code. Each basic block comprises a set of computer instructions that are always 
executed together, e.g., in series. 

The Office Action points to column 3, lines 35-60 and column 7, lines 10-20 for 
showing (3:35 - 60, for sorting see execution order, also see 7:10 - 20, and also mentions "for 
sorting see execution order" (Office Action, page 3, lines 21-23). Column 3, lines 35-60 set 
forth background, objects and summary of the invention of Kawahito. The phrase, "execution 
order" is mentioned in line 59 of column 3 and relates to the third optimization method 
described by Kawahito. In the third method described by Kawahito, redundant array range 
checks are eliminated by collecting information about array range checks already processed 
using data-flow analysis in execution order. Thus, Kawahito describes performing data-flow 
analysis to determine where array range checks can be eliminated. The phrase, "execution 
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order" does not in any way anticipate, "sorting the index expressions by trip counter and 
offset" set forth in the independent claims as mentioned above. 

Column 7, lines 10-20, mentioned in the Office Action at page 3, lines 21-23, also 
discusses the third process described by Kawahito. This discussion actually begins at column 
6, line 53 and is made with reference to Figure 7. Specifically, this process "eliminates 
redundant array range checks by using data-flow analysis" (column 7, lines 3-4). Lines 10-20 
specifically mention steps for collecting array range check information. The second step 
involves collecting array range check information where an integer is added to or subtracted 
from the index variable. This can be expanded to collecting a range defined by upper and 
lower bounds which can be handled as already checked from a minimum constant offset and a 
maximum constant offset of an array index in the array range check and the lower bound of 
the array. It should be noted that there is no suggestion here, or anywhere else in Kawahito, 
for "sorting the index expressions by trip counter and offset" as presently set forth in the 
independent claims. 

Since Kawahito fails to disclose, either expressly or inherently, each and every 
limitation set forth in independent claims 1, 27, 31, and 35, Applicants respectfully submit 
that the claims are not anticipated by Kawahito. Furthermore, since the remaining claims 
depend from one of independent claims 1, 27, 31, and 35, Applicants respectfully submit that 
they are allowable for at least the same reasons as the independent claims as explained above. 
Applicants therefore submit that all pending claims are allowable over the prior art of record. 

Dependent Claims separately patentable 

The dependent claims 2-6, 28-30, 32-34, and 36-38 further define the invention and 
distinguish it from the prior art. For example, claim 36 sets forth, inter alia, receiving byte 
code from an interpreter, determining whether native code corresponding to the bytecode is 
available; incrementing a counter when native code is not available, and interpreting the byte 
code when the counter is below a threshold. The Office Action merely states that, "Regarding 
claim 36, which recites similarly to claim 1, see reasoning as previously discussed above" 
(page 5, lines 18-19). Applicants respectfully point out that claim 1 does not contain these 
limitations. Furthermore, none of the references teach or suggest elements set forth in claim 
36 or the other remaining dependent claims. Since the dependent claims are separately 
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patentable, Applicants respectfully submit that they should be allowed even if the independent 
claims are held to be unpatentable. 

Applicants respectfully submit that this Application is now in condition for allowance. 
Examiner is invited to contact the undersigned by telephone at (408) 749-6900 X6933 if he 
has any questions regarding this Amendment or to resolve any remaining issues. If any other 
fees are due in connection with filing this amendment, the Commissioner is also authorized to 
charge Deposit Account No. 50-0805 (Order No. SUNMP018). A duplicate copy of the 
transmittal is enclosed for this purpose. 



710 Lakeway Drive, Suite 200 
Sunnyvale, CA 94085 
Telephone: (408) 749-6900 
Facsimile: (408) 749-6901 



Customer Number 32291 



Respectfully submitted, 
MARTINE & PENILLA, LLP 



Leonard Heyman, Esq/ 
Reg. No. 40,418 
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Abstract 



Data flow analysis is a well studied family of static program analyses. A rich theoretical 
basis for data flow analysis has been developed. Centred to this theory is the concept of data 
flow framework. These frameworks are a semantically well-founded formalism for specifying 
a data flow analysis. A variety of solution algorithms for problems specified as data flow 
frameworks have been developed. 

The bulk of the research on data flow analysis has been done in the context of analysis 
of sequential programs. Unfortunately, a number of important assumptions of this work are 
violated when we apply data flow analysis results to concurrent programs. In this paper, 
we extend data flow frameworks for sequential program analysis to accommodate concurrent 
programs. We present solution algorithms for these extended frameworks and reason about 
their convergence and complexity. 



1# This work was supported by the Advanced Research Projects Agency under Grant F30602-94-C-0137. 



1 Introduction 



Data flow analysis is a process for uncovering facts about executable program behavior 
without actually running the program. With applications to compiler optimization, pro- 
gram testing, validation and verification, data flow analysis is an important technique for 
a variety of software development activities. The constant desire for faster programs has 
spurred tremendous theoretical and practical advances in program analysis and optimiza- 
tion techniques. The bulk of this work has been for sequential programs. 

The development of data flow frameworks by Kildall [Kil73] marked the beginning of a 
new era in compiler optimization. Setting data flow analysis on a sound formal foundation 
spurred a wealth of research into both generalizing, e.g., [KU77, CC77, GW76, Tar81] and 
specializing Kildall's result, e.g., [KU76, WZ91, Tar81]. This resulted in formalisms for 
specifying and classifying data flow analysis problems, and the development of algorithms 
for solving any problem in a given class. This meant that compiler developers no longer 
had to hand-craft a system of equations and a solver for an analysis problem. Instead, the 
formal machinery of data flow frameworks could be used to describe a data flow problem 
and to guide the selection of an appropriate ready-made solution algorithm for that problem* 
thereby, reducing the cost of building analyzers. 

Compiler optimization research has adapted to the emergence of concurrent and parallel 
computing into the programming mainstream A large body of work has been developed 
for using data flow analyses to aid in parallelizing of sequential programs, e.g., [ZC91]. 
More recently, data flow analyses and optimizations for explicitly concurrent and parallel 
programs have been investigated, e.g., [SHW93, GS93]. Unfortunately, the theory of data 
flow frameworks has not been updated to accommodate the new program representations 
and analyses that concurrency and parallelism have brought. 

In this the next section, we present a review of data flow frameworks. Section 3 follows with 
a discussion of the limitations of those frameworks. In Section 4 we present a generalization 
of Kam and Ullman's monotone data flow analysis framework [KU77]; this generalization, 
called a complete-lattice monotone data flow analysis framework, supports the formulation of 
data flow analyses over flow graphs for concurrent programs. We present solution algorithms 
for data flow analysis problems formulated as complete-lattice frameworks and prove results 
related to their correctness and complexity. To illustrate these ideas, in Section 5 we discuss 
the formulation of a well-studied data flow analysis problem as a complete-lattice framework. 
Section 6 mentions future directions and concludes. 

2 Background 

We begin with some definitions and terminology. In this section, we present results about 
data flow analyses formulated as data flow frameworks, using the terminology and definitions 
in Hecht [Hec77]. 

Every data flow analysis problem computes a different kind of problem information. This 
information captures facts about executable program behavior that the analysis is designed 
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to gather; this information is inherently approximate. We can gather more(less) precise 
approximations with a commensurate increase(decrease) in the cost of analysis. 



Definition 1 A meet semi-lattice is a triple, L = (V, C,n), where V is a set of values, 
C is a "partial-order defined over V, and I~l is binary operation defined over V, such that the 
following semi-lattice properties hold: 



sny □ y (1) 

x Fly — x <=> x Qy (2) 

x PI x — x (3) 

xF\y = y l~l x (4) 

(xr\y)r\z = xn(y\lz) (5) 

3-L G V : Vs € V : JL C x (6) 



The lattice values encode information about the program that we are interested in collecting. 
The values in V are partially-ordered by the □ operator; this describes which values contain 
the information of other values. The meet operator n|V x V — > V is used for combining 
values. Intuitively, the bottom value, J_, is less than all other lattice values if we interpret 
C as <. We can optionally have a top value, T, that is greater than all other values. A 
chain in the lattice is a collection of values that are all ordered with respect to one-another; 
it is a linear ordering of lattice elements. While V need not be finite, for our purposes we 
are only interested in lattices that have chains of finite length; note that we allow infinitely 
many such chains. The height of a lattice is the length of the longest chain. The standard 
example of a meet-semilattice is a powerset, V(S), where the values are subsets of a given 
set, Si C 5, the values axe ordered by C and meet is fl. For this lattice _L = 0, T = 5, and 
its height is the number of elements in S. 

Definition 2 A function space F over a meet semi-lattice, is set of functions, f\V — ¥ V, 
defined over the lattice values. 

The functions in F, called transfer function } are used to capture the local effects of parts 
of the programs computation. There are a number of function space properties that can be 
used to classify a function space with respect to a lattice: 



: V»ey:M»)=« (7) 

VvEV : 3f v €F:Vx<EV:f v {x)=v (8) 

V/.flfGF : fogeF (9) 

V/GF : Vx,yeV:f(xny)Qf(x)nf(y) (10) 

V/GF : Vx,y€V:f{xny) = f(x)nf(y) (11) 
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Definition 3 A monotone function space satisfies properties 7-10. 

Definition 4 A distributive function space satisfies properties 7-11. 

Combining a lattice of values and a collection of transfer functions yields a, somewhat 
abstract, description of a class of data flow analysis problems. 

Definition 5 A data flow framework is a pair, D = (L, F), where L is a meet semi- 
lattice and F is a function space defined over that lattice. 

The set of possible program executions are modeled as a rooted directed graph. 

Definition 6 A flow graph is a directed graph, G = (N,E y n 0 ), where N is set of nodes, 
E is an edge relation over nodes, and Uq G N is a distinguished start node. 

For our purposes we restrict the set of edges such that Vm G N : (m,n 0 ) 0 E. For 
convenience, we define the set of predecessor, Preds(n) = {m : (m,7i) G E}, and successor 
nodes, Succs{n) = {m-: (n, m) G E}. 

Associating the components of a data flow framework with components of a flow graph 
yields a more concrete description of a class of data flow analysis problem. 

Definition 7 An instance, I = (G, M) of a data flow framework, D, is the binding of 
transfer functions to flow graph nodes. This binding is accomplished through the definition 
of a function map, M\N — > F. 

This mapping associates a function from F with each node; the transfer function captures 
the effects of that node with respect to the information being gathered and represented as 
lattice values. For convenience, we will write the function M (n) as /„. 

The solution of a data flow analysis problem is an approximation to the problem informa- 
tion at each node in the flow graph. Data flow analysis problems can be formulated directly 
as equations that give the information for a node in terms of the information at its prede- 
cessors and functions that capture the local effects of a node: 

X W = fn {X[n predl ] , . . . , X [npr^ } ) 

Where X[n] is the problem information at node n. A data flow framework is a formalism for 
describing a class of data flow analysis problems. It provides the types for the X[.] variables 
and the functions /. An instance of a framework provides information that tells us which 
variables and functions to equate; thus, providing a system of related equations: 

X[n 0 ] = ± 
Vn G N - {n 0 } : X[n] =■ n i€Predl(n) /i(X[i]) 
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A data flow analysis problem is solved by computing a fixed point of the equation system. 
This solution associates a lattice value, representing problem information, to each flow graph 
node. For problems formulated as an instance of a monotone data flow framework, the 
maximum fixed point (MFP) can be computed efficiently and is known to be unique. If the 
framework is distributive, then the MFP solution contains, for each node, the maximum 
amount of problem information that can be computed by considering every path from the 
start node to the given node; this is called the meet over paths (MOP) solution 2 . This 
solution is made possible due to the fact that fl distributes over / G F. We can move 
the l~l operations to the outside and apply it a single time to / P (-L). Where for a path, 
p = 7i 0 ,7ii, . . . ,7ifc, the composition of transfer function of the nodes on the path is / p (.) = 
• * (/ni(/no(-))) * • •)• We define the set of paths leading from n 0 to node n as Paths(n) =' 
{P\P = no, . . . >7ik = 7i } where, for integer i such that 1 < i < k we have (ni_!,n;) G E. 
Given this we can write the MOP solution as: 

A [n] = n p€Patha ( n ) f p ( _L ) 

3 Limitations of Semi-lattice Frameworks 

Placing data flow analysis on a sound formal foundation has brought many advantages to 
developers of new analyses. The ability to characterize an analysis framework [MR90], as 
rapid, continuous, distributive, monotone, or k-bounded for example, allows one to apply 
existing theoretical results to reason about convergence, bounds on running time, and the 
precision of analyses. In addition, a wide variety of general and specialized algorithms have 
been developed for classes of frameworks. Making it easy for developers of new analyses to 
choose the algorithm that is most appropriate for their data flow framework formulation of 
a problem. 

The application of data flow analysis has been primarily in compiler optimization. His- 
torically, the mean thrust of that work has been on producing small/fast executables for 
programs written in sequential programming languages. The algorithmic and theoretical 
developments related to data flow analysis have mirrored this work by focusing on sequential 
programs. There has been some recent work on applying data flow analysis to concurrent 
programs. Like the early work on sequential program analysis this newer work has, to a 
great extent, involved the development of ad-hoc solutions to important practical problems. 

As with all static analyses, data flow analyses reason about a model of program execution, 
i.e., the flow graph. A flow graph model can represent varying amounts of program informa- 
tion; it need only be sure to represent all the information that is necessary to support safe or 
conservative analyses. Given the wide variety of possible flow graph models it is fruitful to 
examine some common assumptions about these models. We discuss two such assumptions 
that underly much of the data flow analysis work to date. 

2 The MOP solution is often referred to as the best possible static solution for a given analysis problem. 
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A Path Models a Program Execution 



Flow graph representations axe often constructed so that for each prefix of a program execu- 
tion that ends at the statement corresponding to node n, there is a path in the graph from 
n 0 to n. Typically, flow graphs will contain some paths that do not correspond to feasible 
executions of the program; this is done in order to represent the large, potentially infinite, 
number of different program executions in a tractable form. 

For sequential programs it is easy to construct a flow graph from the source text. For 
programs written in high-level programming languages such a flow graph is typically sparse; 
each node only has a few neighbors. For interacting concurrent programs flow graph is more 
complicated to construct and often has a higher degree of node-connectedness. 

Many models of concurrency allow for communication between processes and support mul- 
tiple senders and receivers over a given communication channel. A flow graph representation 
for a program using this model must pessimistically assume that all pairs of senders and 
receivers for a given channel can communicate; although analysis may be able to determine 
the impossibility of certain communications. Thus, the number of nodes in the flow graph 
will, in the worst-case, be quadratic in the number of program statements rather than linear. 

In order for all feasible program executions of a concurrent program to be represented as a 
flow graph path, we must represent all possible interleavings of the independently executing 
statements in program processes. Even with exact information about the statements that 
can execute concurrently, the flow graph would still be very dense, i.e., \E\ will approach 
|iV| 2 . Unfortunately, the problem of computing that information is NP-complete [Tay83]. 

As a consequence of this second implication, researchers have developed flow graphs that 
do not explicitly represent statement interleavings; these include the SCG [CKS90], PFG 
[GS93], MIG [Due91], and sync hypergraph [MR93]. There are also flow graphs that can be 
viewed with or without explicit interleavings, such as the TFG [DC94]. Figure 1 depicts flow 
graphs for a sequential and a concurrent program. The sequential flow graph is standard. 
The concurrent flow graph can be viewed as a collection of sequential control flow graphs, 
one for each process in the program (enclosed in a dashed box), consisting of (circular) nodes. 
Additional (square) nodes represent synchronization or communication points. Note that we 
are not attempting to define an all inclusive model of flow graphs for concurrent programs, 
rather we axe identifying a number of common structured and semantic modeling features 
that differentiate them from flow graphs for sequential programs. The specific flow graphs 
mentioned above are all quite similar to the concurrent flow graph as described here. 

These concurrent flow graphs model a program execution as a collection of paths, one for 
each process sub-graph, where those paths intersect at process interaction points. For such 
graphs, the MOP is no longer the best possible solution; in fact, it can be quite imprecise. 
Consider a classic any-path forward-flow data flow analysis problem such as reaching defini- 
tions [ASU85]. A definition of variable v at node d is said to reach a use at node u if there 
exists a path from d to u on which d is not killed, i.e., v is not re-defined. For the concurrent 
flow graph in Figure 1, if def x , def 2 and use all refer to the same variable, the MOP solution 
for this problem would say that defi reaches use. If the successor square node of defi is a 
synchronization node, however, then defi is killed by cfe/2 on all program executions leading 
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Figure 1: Typical Sequential and Concurrent Flow Graphs 



to use. 



Semantics of flow graph merge points 

The semantics of merge points in such a sequential flow graph are uniform; a merge repre- 
sents the confluence of two distinct program executions. In a concurrent flow graph nodes 
and edges model control flow information, synchronization information and communication 
information. Consequently, merge points can represent the confluence of parts of two distinct 
program executions or different parts of the same program execution. 

For data flow analysis, flow graph merge points serve an important role; they are the 
points at which data gathered from separate regions of sequential program execution are 
combined. In meet semi-lattice data flow frameworks this combining operation is the meet 
operation. For the concurrent flow graphs described above, it appears that being limited to a 
single combining operation can lead to significant imprecision in analysis results. Srinivasan 
[SHW93] has also identified the necessity of multiple combining operations, represented as 
</> and ij) nodes, in defining an SSA form for explicitly parallel programs. 

4 Complete-lattice Frameworks 

In this section, we generalize semi-lattice frameworks to allow formulation of data flow prob- 
lems over a complete-lattice. We extend a number of important results for monotone semi- 
lattice frameworks to complete-lattice frameworks. These new results address the limitations 
of semi-lattice frameworks and make the advantages of frameworks available to developers 
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of analyses for concurrent programs. 



Definition 8 A complete-lattice is a triple, L = (V, E,n,l_l), where V is a set of values, 
□ is a partial-order defined over V, and fl and U are binary operation defined over V . These 
operations are such, that for all subsets S C V, l~l ae s and U ae s are definecP . In addition 
to the semi-lattice properties (1-6), the components of L must satisfy the following lattice 
properties: 



xUy □ y (12) 

x Uy = y x tl y (13) 

xUa; = x (14) 

xUy = y U x (15) 

(xUy)Uz = xU(yUz) (16) 

xU(xHy) = x (17) 

x\l(xUy) = x (18) 



A complete-lattice is essentially a meet semi-lattice with an additional idempotent, associa- 
tive, commutative operation U called join. Height and T are defined in the same way as for 
a semi-lattice. The standard example of a complete-lattice is a powerset, V(S), where the 
values are subsets of a given set, 5i C 5, the values Eire ordered by C, meet is fl, and join is 
U. For this lattice J_ = 0, T = S } and its height is the number of elements in S. 

Observation 1 If we have a finite collection of lattice values a?i, x 2 , . . . , a/, x 2 \ . . . , scjfe' G 
V , where for i such that 1 < i < k we have X{ Q Xi, then r\i<i<kXi □ ^x<i<k^i and 

This follows from Lattice properties 1, 18 and the associativity, and commutativity of Fl and 
U. 

We define a function space, F, over the values, V, just as we do for a semi-lattice. Mono- 
tonicity and distributivity of the function space requires that function space properties (7-10) 
and (7-11), respectively, be met. 

Definition 9 A complete-lattice data flow analysis framework, is a pair, D = 
(L } F), where L is a complete-lattice and F is a function space defined over that lattice. 

Definition 10 An instance, I = (G, AT n , N u , M), of a complete-lattice data flow 
analysis framework, D, is a quadruple consisting of a flow graph G, subsets of the flow 
graph nodes N n and N u , and a function map M\N — > F, where: 

3 This is the standard lattice-theoretic definition of a complete lattice [DP90]. 
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n Q & N n 

no g N u 

N n HN u = 0 

N = N n U N u U {n 0 } 

The set N n contains the flow graph nodes for which l~l is used to merge predecessor values. 
The set N u contains the flow graph nodes for which U is used to merge predecessor values. 
Intuitively, these sets serve to map merge operations onto flow graph nodes just as M maps 
transfer functions onto flow graph nodes. A complete-lattice framework describes a class of 
data flow analysis problems; it induces the following system of simultaneous equations: 



X[n 0 ] = JL 
Vn G N n : X[n] . = n pePreda{n) f p {X\p\) 
Vn G N u : X[n] = U pG p redtf ( n )/ p (X[p]) 

We note that if N u = 0 then this equation system is equivalent to one derived from the 
semi-lattice framework embedded in the complete-lattice framework. A data flow analysis 
problem is solved by computing a fixed point of the equation system, as described above. 

Solving Complete-Lattice Data Flow Problems 

We generalize existing results for monotone semi-lattice frameworks to monotone complete- 
lattice frameworks by mirroring Kam and Ullman's generalization of Kildall's distributive 
semi-lattice frameworks [KU77]. 

In the following, we assume the existence of T. If it does not exist we can introduce a new 
element and adjust the lattice and functions accordingly, such that: 



TUx = xUT = T 
/CO = T 

Algorithm 1 (General Iterative Solver) 

Input: 

An instance / = (G, AT n , N U} M) of D = (L,F), a monotone complete-lattice 
framework. 



Output: 



8 



A lattice value for each node, Vn G N : A[n] G V. 



Initialization Step: 



v/ xr a r i f i t/n = % 

v^etf ^W = ( T J othe 



otherwise 



Iteration Step: 



Visit the nodes, other than n 0 , in order n u n 2) Nodes can be visited multiple 

times and the order is not fixed prior to running the algorithm. A visit of a node, 
n, is the evaluation of one of the assignments: 



A[n] = r\ pePreds{n) f p {A\p]) if 7i G AT n 
A[n) = U pePre ^ (n) / p (A[p]) if u G N u 



The sequence of nodes visited must satisfy two conditions: 

No premature termination If there exists a node n G N n (*i G AT U ) such that 
<A[n] ^ n p€Pred5(n) / p (A[p]) (A[n] / U p€Pp «£.(n)/ P (A[p])) after visiting node m 
in the sequence, then there is an integer j > i such that nj = n. Intuitively, 
if we reach a point in the sequence where some node's current value has not 
been updated by newer information at its predecessors then the sequence must 
continue until that update is performed. 

Termination after stabilization If after visiting node n;, 
A[n] = n p z Pred3{n) f p {A\p}) for all n G # n and A[n] = U pGPpeda(n) / p (A[p]) for 
all 7i G N u , then the sequence will eventually halt. Intuitively, once we have 
reached a point where all the current node values are up to date it is safe to 
terminate the algorithm. 

In the presentation that follows we will refer to the j th step of Algorithm 1 to mean the 
state of the algorithm after visiting the first j nodes in the node sequence. The value at a 
node, ra, on the j th step will be denoted i4^[n]. 

The constraints on the node visitation sequence express certain requirements of the algo- 
rithm with respect to termination; they do not, however, guarantee termination. 

Lemma 1 (General Iterative Solver Terminates) 

Given an instance instance, I — (G, N n , N Ul M) } of a monotone complete-lattice dataflow 
analysis, D = (L,F), if we apply Algorithm 1 it will eventually terminate. 

Proof: The proof is by induction on ra, the number of steps performed by Algorithm 1. We 
show that. for all nodes, n, in G, A< m+1 )[n] □ A^[n]. 
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Base Step: m = 0 

At this point the algorithm has completed its initialization phase and visited a 
single node, n\. For the start node, n 0 , we have A^fno] = 1 E -L - ^ 0 )[n 0 ]. We 
have yet to visit any of the other nodes, n E N — {no,ni}, and those nodes remain 
at their initial values, so j4W[»] = TCT = We visit rti on this step, but 

since the value at step 0 at n\ was T we do not need to bother evaluating A^^ni]; 
by definition all values axe C T. 

Inductive Step: At step m+lwe have Vn E N : A^[n] C A( m_1 )[7i] 

At this point in the algorithm we are at step m + 1 and have just visited node 
n m+ i. We note that at each step in the algorithm the value of at most a single 
node can change; for step i it is the value at node 7i{, Thus, for the values at node 
n E N — {n m +i} will remain unchanged, so: 

VnG AT-{7i m+1 }: A^ l \n] = A^[m] => A^\n\ C A^[m] 

Let / be the most recently preceding step at which node n m+ i was visited; 
if n m+ i has never been visited then I = 0. The sequence of node visits is 
. . .n t , • • • |TO m ,n m+ i . . ., where n t = n m+1 . 

If for all i such that Z < i < m + 1, it is the case that n,- ^ Preds(n m +i), 
then i4^ m+1 ^[n m+ i] = ,4( m )[n m +i] = A'''[n m+ i], since none of its predecessors have 
changed value. In this case the induction trivially holds. 

If there exists an i such that / < i < m + 1 and rti E Preds (7i m+1 ), then 
some number of predecessors may have changed value. We refer to the set of 
predecessors of n m+i who have changed value since step / as Changed] we also 
define NotC hanged = Preds(n m +i) — Changed. There are two cases to consider 
in evaluating the new value at n m+ i: 

case 1: n m+1 E N n 

We write out the values at steps m and m + 1 more explicitly to show their 
relationship. 

A™[n m+1 ] = A^[n m+1 ) 

= {r\ peChange dfp{A {l) \p])) n [n^ffotChangcdfpiA^lp])) 
n m+l = {n p eCha n gedf P {A( m) \p])) U {n peNotCh an g edf P {A {l) \p])) 

Focusing on the right hand side of these two equations, we have: 

VpeNotChanged : f P {A^[p])) C f P {A^\p])) 
VpG Changed : f P {A^\p})) Q f p (A^\p})) 
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from the definition of C and the inductive hypothesis. By Observation 1 the 
iterated meets of the elements on the right hand sides satisfy the C relation. 
So, A( m+1 )[n m+1 ] C A( m )[n m+1 ] and the induction holds, 
case 2: n m+1 G N u 

We write out the values at steps m and m + 1 more explicitly to show their 
relationship. 

A^[n m+1 ] = A^[n m+l ] 

= (U p6Cfca n ffe <i/p(A(')[p]))U(U p€jVotChonfle< ,/ p (A(')[p])) 
>i (m+1) [n m+1 ] = (U p6 C fc «n^/p(^ (m) [p]))U(U p6J v ot c^ nffe<i / p (A ( ' ) [p])) 

Focusing on the right hand side of these two equations, we have: 
Vpe NotC hanged : f P (A^\p})) Q f p {A^\p})) 
VpE Changed : f P (A lm) \p\)) E / P (A«[p])) 



from the definition of E and the inductive hypothesis. By Observation 1 the 
iterated joins of the elements on the right hand sides satisfy the C relation. 
So, A( m+1 )[n m+1 ] C A( m )[n m +i] and the induction holds. 

We now turn our attention to the conditions for node visitation sequences. After 
the i th step we have one of two cases, either the values have stabilized, in which 
case the sequence will terminate, or there is some value that has yet to be updated 
and the sequence continues. The premature termination condition guarantees that 
a node that needs updating will get updated. There are a finite number of nodes 
in G; for each node there axe a bounded number of values that can be taken on 
in descending through the lattice, since the lattice has finite length chains and a 
J_ element. Consequently, node updates can occur only a finite number of .times. 
Therefore, the sequence is finite and the Algorithm 1 terminates. 

□ 

We now show that the solution computed by this algorithm is, in fact, the maximum 
fix-point of the system of equations described earlier. 

Theorem 1 (General Iterative Solver Computes MFP) 

Given an instance, I = (G, N n , N U) M), of a monotone complete-lattice dataflow analysis 
framework, D — (L, F), if we apply Algorithm 1 then the solution, the A[n), is the maximum 
fix point solution of the following system of equations: 

X[n 0 ] = _L 
Vn € tfn : *[n] = n pePred , (n) / p (*[p]) 
VneN u :X[n] = U pGPred . (7l) / p (X[p]) 
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Proof: By the definition of the algorithm it is clear that once Algorithm 1 halts, the A[n] 
are solutions to the above equations. We need to show that these A[n] are greater or equal 
to any other solution to the equations, B[n\. We prove, by induction on m, the number of 
steps taken in Algorithm 1, that after the m th step Vn G N : B[n] C A( m )[n]. 

Base Step: m = 0 

The only possible solution at node 7z 0 is _L, so B[n 0 ] = _L. At step 0 we have com- 
pleted initialization so A^no] = -L, and the induction holds. For the other nodes 
n G N — {n 0 } the initial value is T, so regardless of its value B[n] CT = A^ra], 

Inductive Step: At step m we have WnEN : B[n) C A (m_1) [7i] 

At step m we visit node n m to compute a new value; all other nodes keep their 
same value, Vn G N — {n m } : A( m )[7i] — A^ m ~ l>i [n]. Using the inductive hypothesis 
we see that the inductive step holds for these nodes. 

To compute the new value at node n m there are two cases: 

n m e N n 

By definition the solution we have i?[n m ] and from the proof of Lemma 1 we 
have: 

B[n m ] - n p ePredB(n)fp{X\p\) 

^ (m) W = n p6Prc(fa(n) / p (^(" l - 1 )[ P ]) 

From the inductive hypothesis we know that 

Vp G Preds(n m ) : B\p] C A (m_1) [p] 
The monotonicity of the function space gives us that 

Vp€ Pred S (n m ) : f p B\p] C f P (A {m ~ 1] \p\) 

From Observation 1, since the elements of the iterated meets in the definitions 
of 5[n m ] and A( m )[7i m ] are pear- wise ordered so are their iterated meets. Thus, 
-B[^m] E ^"^f 71 ™] an d the inductive step holds for n m . 
n m G N n 

By definition the solution we have 5[n m ] and from the proof of Lemma 1 we 
have: 

B[nm] = U pGFrc(fa(n) / p (X[p]) 
A (m) W = U pePreda{n) f p (A^-%)) 

From the inductive hypothesis we know that 

Vp € Preds{n m ) : B\p] Q 
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The monotonicity of function space gives us that 

Vp 6 Preds(n m ) : f p B\p] Q f p (A^\p}) 

Prom Observation 1, since the elements of the iterated joins in the definitions 
of 5[7i m ] and A^ m )[n m ] are pair- wise ordered so are their iterated joins. Thus, 
B[n m ] C A( m )[7i m ] and the inductive step holds for n m . 

The theorem follows from these results and the fact that Algorithm 1 is guaranteed 
to terminate by Lemma 1. 



Algorithm 1 is specified as weakly as possible; more refined implementations are free to 
choose from a wide variety of data structures and node visitation orders. We describe one 
such implementation here. It is an adaptation of Hecht's iterative worklist algorithm [Hec77]. 

Algorithm 2 (Iterative Worklist Solver) 

Input: 

An instance / = (G, AT n , N u , M) of D = {L y F), a monotone complete-lattice 
framework. 

Output: 

A lattice value for each node, Vu £ N : A[n] G V. 

We use two auxiliary data structures in this algorithm: W which is an ordered sequence of 
nodes with at most \N\ elements and v a single lattice value. 



Initialization: 



VneN A[n] = ( ± = n ° 

[ T otherwise 

W = {m : (7i 0 ,m) <E E} 



Main Loop: 

We evaluate the following statements repeatedly until W = 0: 4 

at this point W = n, n x , n 2 . . . n*. 

(1) W = nx 9 n 2} ...n k 

(2) v = A[n] 

(3) if n G N n then 



4 We describe the worklist as initially containing k + 1 elements; this is a notational convenience and if 
Jb = 0 then W = n. 
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(4) A[n] = n pePreda(n) f p (A\p]) 
else 

(5) A[n] = U p ePreds(n)fp{A\p\) 

end if 

(6) if v ^ A[n] then 

(7) W = n u n 2j ... i n k ,n ai ,n 8J) ... 

where n ai £ Succs(n) and for 1 < I < A; n 8i ^ n\ 
end if 

We now show that this iterative worklist solution algorithm computes the same results as 
the general solver algorithm, which was shown in Theorem 1 to be the MFP of the induced 
system of equations. 

Theorem 2 (Iterative Worklist Solver Correctness) 

Given an instance, I — (G> N n , N Ui M), of a monotone complete-lattice dataflow analysis 
framework, D = (L, F), if we apply Algorithm 2 then the solution, the A[n], is the maximum 
fix point solution of the following system of equations: 

X[n 0 ] = ± 
VneN n :X[n] = n pePreMn) f p {X\p}) 
VneN u :X[n] = U pePreda{n) f p {X\p}) 

Proof: Recall that Algorithm 1 operated by performing a sequence of node visits, where 
the sequence had two constraints. We prove this theorem by showing that the computation 
performed by Algorithm 2 is equivalent to such a sequence of node visits. 

The initialization phases of both algorithms axe identical. A visit in Algorithm 1 
is equivalent to executing statements 3-5 in Algorithm 2. The rest of the statements 
in Algorithm 2 are used to maintain the worklist, W, which enforces the node 
visitation sequence. We show that these statements work together to satisfy the 
conditions on visitation sequences expressed in Algorithm 1. We consider just the 
case of nodes in N n ] for nodes in N u we make an identical argument. 

No premature termination The condition states: 

if 3n G N n : A[n] j= ^pePreda{n)fp{A\p\) after visiting node U{ in the 
sequence, then there is an integer j > i such that nj = n. 

Let the last time we visited node n be at step last where last < i, 
ni a ,t - n. We have A^'%n] = ^p^.^f^A^-^}). The only way 
that D pe p re ds(n)fp{A\p\) can change value is if one of the predecessors, say p 1? 
changes value and that requires a visit to node p x . Let such a visit occur at 
step new where last < new < i and there are no other visits to p\ at steps last 
through new — 1. This visit will occur on the new th iteration of the body of 
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Algorithm 2; we remove p x from the head of W. Line 2 of the algorithm saves 
the old value of A\pi] which is A( ioat )[pi] in our local variable v. Our visit of pi, 
lines 3-5, compute a new value ^""^[pi] □ ^'"^[px]; the values are not equal 
because of the assumption that the predecessor changes its value. The test at 
line 6 succeeds and we proceed to add all successors of p\ to W that axe not 
already in W. Thus, we are assured that n is on the worklist after our visit 
topi. Since, the worklist contains at most |iV| elements we are guaranteed to 
visit node n before step i + \N\ + 1. Thus, the condition is satisfied since there 
exists a j such that i < j < i + \N\ + 1. 

Termination after stabilization The condition states: 

If after visiting node n;, A[n] = ^ P ePred3{n)fp{A\p\) for all n G AT n , 
then the sequence will event ually halt. 

After we visit node U{ we may visit additional nodes. Let n be the next node 
we visit at step i + 1; it is taken off of W at line 1. We store the current value 
[n] in local variable v at line 2. Our visit to node n, in lines 3-5, computes 
J 4(»+ 1 )[ n ] = n p6 p re( f tf ( n )/p(AW[p]). The assumption in the condition is that 
A^[n] = n p€Pred3[n) f p {A^\p}) for all n G N n . So, A^ l )[n} = A®[n] = v and 
the test at line 6 fails; we add no nodes to W. Subsequent iterations all behave 
in the same way because the visits i,i + 1, . . . cause no change to A[n] for all 
n G N n - Since we never execute line 7 in any of these visits, each visit reduces 
the number of elements on W by 1. Thus, there can be at most \N\ — 1 more 
iterations of the body of Algorithm 2 after the i th , and the sequence of node 
visits halts at j where j < i + \N\. 

Since all phases of Algorithm 2 meet the specification of Algorithm 1 our theorem 
holds by Theorem 1. 

□ 

We can express a bound on the running time of this algorithm in terms of the height, k } 
of L. 

Theorem 3 (Iterative Worklist Solver Complexity) 

Given an instance, I = (G, 7V n , N U} M), of a monotone complete-lattice dataflow analysis, 
D = (L,F) f where L has height k } if we apply Algorithm 2 it will terminate in 0(k\N\ 2 ) 
time. 

Proof: 

The initialization phase requires 0(|AT|) operations to assign values to each node 
and 0(| AT |) operations to initialize W. 

We use W as a queue that contains at most a single instance of each element. 
Lines 1 and 7 require standard enqueue/ dequeue operations. Querying whether 
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W has a given successor node in line 7 requires a containment test. Both of these 
requirements can be handled efficiently by implementing W as a collection of nodes 
that is threaded as a queue and also threaded as bucket elements of a hash table; 
hashing on node identity is straightforward. In this case, lines 1-3 and 6 all require 
0(1) operations. 

The cost of lines 4 and 5 are equal, so we consider only one of them. Line 4 is 
the iterated meet over all predecessors, of the predecessors transfer function applied 
to the predecessors current value. A standard, and reasonable, assumption is that 
transfer functions, / n , require 0(1) operations to evaluate. Thus, line 4 requires 
0(|iV|) 5 operations since in the worst-case a node may have all other nodes as 
predecessors. 

Line 7 requires that for each successor, we check for containment in W\ if not 
contained we append the successor to W. The containment check requires 0(1) 
operations, since it is a hash table lookup, and the append requires 0(1) operations. 
Thus, line 7 requires 0(|7V|) operations since in the worst-case a node may have all 
other nodes as successors. 

In toted the body of the main loop requires 0(|iV|) operations. 

The number of iterations of the body, or visits to a node, can be bounded by 
making use of the conditions on the node visitation sequence from Algorithm 1. It 
was shown in the proof of Theorem 2 that the sequence of nodes taken from the W 
satisfies those conditions. Recall, from the proof of Theorem 1, that the values at 
all nodes in the graph cure descending monotonically through the lattice from T; the 
lowest they can go is _L. In the worst case, each iteration of the main loop causes 
a single node to descend a single value in the lattice; multiple nodes descending 
multiple values in a single iteration is quite possible but only makes the algorithm 
converge faster. At least one node will descend otherwise the termination after 
stabilization condition guarantees that Algorithm 2 we will terminate in at most 
\N\ steps. At most a node can descend A;, the height of the lattice, times before it 
hits _L Since there axe \N\ nodes in the graph there axe at most k\N\ descending 
iterations. Thus, there are 0(/c|AT|) iterations of the main loop. 

The theorem holds since 0(k\N\) iterations of 0(|AT|) operations is 0(k\N\ 2 ). 

□ 

Algorithm 2 is a practical improvement over Algorithm 1 because of the node visitation 
order it enforces. Nodes are only visited when they have the potential to change value. If 
the sequence of nodes removed from the worklist is . . . tz;, n t +i , . . . , rij . . . and U{ — nj — n 
then there is an integer k such that i < k < j and E Preds(n)\ intuitively, we only put a 
node on the worklist if one of its predecessors changes values. 

Careful consideration of Algorithm 2 reveals a number of additional opportunities for 
eliminating unnecessary computation. As described, for each node the algorithm stores a 
value that does not reflect the effects of the transfer function at that node; this is called 

5 Evaluating a binary- tree of meets would require only 0(log\N\) operations. In this analysis we don't 
bother doing that because the cost of this step is dominated by the cost of line 7. 
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the in value for a node. We can easily modify Algorithm 2 to keep track of the value that 
reflects the effects of a node's transfer function; this is called the out value for a node. We 
can perform the comparison out[n) ^ in{s) where s £ Succs{n) to determine whether the 
value computed at n can possibly affect the value at s. If it cannot, then there is no need 
to put s on the worklist. We can also keep track of the set of predecessors of a node n that 
have changed value, call it Changed, and only compute in(n) = in(n) fl (n p€ changedOut(p)) 
rather than considering all predecessors. These optimizations do not improve the worst-case 
time bound for Algorithm 2, but for dense graphs and graphs whose nodes have high fan-in 
or fan-out they can yield significant practical speedup. 

* 

5 An Example 

To illustrate the utility of complete-lattice data flow frameworks, we consider an example 
data flow analysis problem, which computes flow graph dominators. Intuitively, for a se- 
quential program represented by a statement flow graph domination captures information 
about statements that must precede the execution of other statements on any program exe- 
cutions in which they both occur; we call this statement precedence information. Formally, 
Dom(m) = n if all paths from 7i 0 to m in G pass through n. This is a safe approximation to 
statement precedence information in the sense that Dom(m) = n implies that statement n 
precedes statement^ on all program executions in which both occur. 

Hecht presents a formulation of it as a distributive semi-lattice data flow analysis frame- 
work [Hec77]: 

L = {V(N),C,n) 

F = {f ide nt(S) = S:SCV(N)}U 

{f n (S) = SUn:ne N AS C V{N)} U 

{fmisc{X) = Y :X y Y QV{N)} 

Where the / m ; 5C are included to make F closed under composition. Note that, for this 
problem, T = N and _L = 0. An instance of this framework is defined as (G, M) where 
M(n) = /„. 

For concurrent programs we are also interested in gathering statement precedence infor- 
mation [CKS90, CK93, DS91, GS93, Mas93]. Unfortunately, using Dam information often 
yields an overly pessimistic safe approximation. Recall the example concurrent flow graph 
in Figure 1. The statement end is clearly preceded by the statement de/i, since all pro- 
gram executions that lead to the last statement of the process must pass through the first 
statement of the process. The existence of paths through the other processes crossing to the 
middle process via one of the square nodes means that this precedence relationship will not 
be captured by the Dom information. 

Intuitively, we want to treat control flow merge points differently from communica- 
tion/synchronization merge points. At a control flow merge point we know that one, but not 
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all, of the predecessor statements has executed immediately prior to the merge. In this case, 
only statements that precede all of those predecessors axe guaranteed to precede the merge 
point. At a synchronization merge point we know that all of the predecessor statements 
have executed immediately prior to the merge. In this case, the statements that precede 
any of those predecessors are guaranteed to precede the merge point. This problem can be 
formulated as a complete-lattice framework problem as follows: 

L = (V{N),c,n,u) 

F = {faentiS) = S : S C V(N)} U 

{f n {S) = Slin-.ne NAS C V(N)} U 
{f mi . c (X) = Y :X,Y CV(N)} 

Where the f m i ae are included to make F closed under composition. Note that, for this 
problem, T = N and _!_ = 0. An instance of this framework is defined as (G, N u , AT n , M) 
G is a concurrent flow graphs whose control flow merge points and synchronization merge 
points are N u and N n respectively. The function map is defined as in the semi-lattice case 
M(n) — f n . Since the lattice is the powerset of the set of flow graph nodes its height is 
\N\. Thus, applying Algorithm 2 gives an 0(|N| 3 ) solution procedure for the problem. The 
bound of this algorithm is equal to the bound of algorithms developed by Callahan [CKS90] 
and Grunwald [GS93] for the statement precedence problem. 

6 Conclusions 

We have extended the theoretical foundations of data flow analysis to accommodate a number 
of natural analysis problems for concurrent programs. The formulation of complete-lattice 
frameworks is compatible with previous semi-lattice frameworks. Thus, a general implemen- 
tation for the complete-lattice frameworks, such as Algorithm 2, is applicable to semi-lattice 
frameworks as well. We have illustrated, by way of example, the ease with which analysis 
problems for concurrent programs can be formulated as a complete-lattice framework. On 
the theoretical front we intend to look at the extent to which distributivity, continuity and 
rapidity [MR90] can be exploited in complete-lattice frameworks. We intend to investigate 
a wide variety of standard and special purpose data flow analysis problems to understand 
the extent to which they are accommodated in the new theory. Given that complete-lattice 
frameworks promise improved precision for data flow analysis of concurrent programs, we 
intend to empirically investigate the extent to which this occurs in practice. 
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